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I* Motivation for the Restructuring 

During our work in providing some new features for the Air 
Force, we needed to create a new type of device driver which 
would be controlled by the I/O Coordinator, However, due to 
the current structure of the driver software, we found this 
task very difficult. Specifically, it would be necessary to 
introduce a new operator response at 10 Daemon initialization 
time and write new software to be executed for the remainder 
of the process. Limitations within existing modules, due to 
the assumptions about possible device types and how they would 
be controlled, prevent their use in new drivers. 

It occurred to us that if we are having this trouble now, 
others will have the same problem in the future as more 
devices, which could be controlled by a device driver, are 
aaaea to the system. For example, the MIT/IPC effort to write 
a spooling tape dim with a command interface shows one attempt 
to add a tape driver within the current structure. In the 
future we may want to add plotters, COM or other devices, 
which may be controlled by queued requests. 

Therefore, now that we have a need for a new driver type, it 
will be easier to generalize the driver structure at this time 
rather than rewrite even more software in the future. This 
MTB addresses this generalization with the following goals: 

1. Allow the easy addition of new driver software for new 
devices (or device classes) without recompiling existing 
software or changing the operator interface except for 
device specific functions. 

2. Separate the driver control software into generic 
functional modules for easy maintenance and sharing or 
tailoring to new drivers. 

3. Generalize the specifications of devices and device classes 
within io_daemon_parms al lowing parameters to determine the 
control module which will be called. 
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II. Problems with the Current Oriver Software 

The statements made in the first paragraph were very general* 
so the following is presented as further Justification. The 
reader may wish to look at the source programs in 
bound_iodd_. s.archi ve in the tools library to clarify some of 
the specifics. 

1. Ail modules of the driver software assume either print or 
pjnch device specifics throughout. Extensive checking of 
new "switches" would be required if this software were to 
be used for new devices. 

2. The format of a user request assumes printer or punch 
control functions which may not apply to other devices. 
(Only a small amount of aata in the front of the structure 
is shared by the 10 Coordinator.) 

3. Current data areas in iodd_static assume that there will be 
no more than two logical devices per physical device (e.g.* 
the printer and punch of a mohawk). This makes the 
aoaition of new multi-function devices more difficult. 

k. Only the remote, module knows how to find the two logical 
devices associated with a multi-function device using the 
"r emot e__t ab" (which also limits the logical devices to 
"prt_name" and "pun_name") • This forces the single 
function ana mu I t i- f unc tion device initialization 
algorithms to be completely different. The limitation of 
mu I t i- function devices to remote, is also seen in 
io_oaemon_parms. 

5. The module input_cmd_, which does general driver command 
processing! assumes that only remote, could have device 
SDecific operator commands. 

6. To share code between the print and punch requests for 
local ana remote drivers (and for historical reasons), the 
module out put_request_ carefully formats printer head and 
tail sheets for punch requests and writes them through the 
di scard_output_ aim. 

7. The module i odd_ I i st en_, which dispatches a user request 
(from the coordinator) to be processed by the driver, 
assumes that only one module knows how to handle the 
request, no matter what device is to be used. 

In summary, the 10 daemon driver is structured as an output only 
driver which Knows how to print and punch with on site or remote 
(mohawk) devices. The dim_name in i o_da emon_parms allows some 
flexibility, but not enough for completely new functions with the 
existing software. 
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I I I . Proposed Changes 

At initialization time for any IO.SysDaemon the operator is 
asked whether the process is to be a "coordinator* driver* 
remote or cards." This will be changed to allow only 
"coordinator or driver"* moving the distinction between remote 
and local drivers until later in the process so we can use 
some common general procedures for assignment of devices and 
device classes. ("cards" does not have to run as 
1 0- SysOaemon. The removal of the "cards" option is the 
subject of another MT3.) 

The current iodo_o verseer_ will take on additional functions 
from io_aaemon_driver_* remote^* and dr i ver_ini t_, providing 
centralization of all initialization code and a uniform 
approach to searching the iod_dev ice_t ab. This is a necessary 
step since the "remote" response has been removed (above) and 
we must now determine the existence of multiple logical 
devices differently. 

To accomplish this* we will introduce the concepts of major 
and minor devices to io_daemon_par ms and to the 
i od_device_tab. A "major aevice" is a generic name associated 
with a physical device. A "minor device" is a generic name of 
a logical device associated with a major device. There may be 
up to ten (10) minor devices per major device. (Ten is an 
aroitrary number chosen to limit table size and still allow 
f lexibi I ity . ) 

Each major device corresponds to a physical piece of hardware 
attached to the process through a physical I/O or TTY channel. 
The per device attributes such as channel* dim* driver module* 
device dial id (for remote devices)* and control terminal dial 
id (see MTB 129)* are associated with the major device. Each 
minor device then has the device type and default device class 
associated with it. 

Now, when the operator is asked to give the "device name and 
optional device class*" he will specify the major device name 
(assume no device class for the present). The module 
i oad_overseer_ will then proceed by requesting the 10 
coordinator to associate each of the minor devices which 
belong to the major device with the driver process. Separate 
driver status segments will be created for each minor device* 
The driver may now behave as separate logical drivers for each 
minor device at its discretion. The driver may even ignore 
one or more of the minor devices. This does not tie up 
resources unnecessarily since they are all part of the same 
physical device and can only be attached to one process at a 
t ime. 
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There are two cases which can arise when the operator 
specifies the optional device class. First, when there is 
only one minor device for the major device (e.g., a printer 
connected to the IOM) the specified device class will override 
the default device class defined in io_daemon_parms. There is 
no ambiguity in the operator's intent in this case. The 
second case occurs when there are multiple minor devices for 
the major aevice. Currently, only the Default device class 
for each device may be used. Since we do not Know to which 
minor device the optional device class should apply, we 
propose that the operator be asked if the specified device 
class is to be associated with each minor device, in turn, 
giving the operator the ability to choose a different device 
class or retain the default for each minor device. This 
approach is chosen to simplify the operator interface for the 
common situation (in fact, it will not change at all) and 
still allow the operator to switch the processing of any 
device class to any driver which can handle it, local or 
r emote . 

A new aata item will be adued to i o_daemon_par ms , called 
"dri ver_modul e". This will be associated with the major 
aevice ana will define the program to be called by 
i odd_overseer_ after the initial driver-coordinator protocols 
are completed. By convention, there will be standard entry 
point names in the driver moaule for initialization, request 
processing, commana processing and condition handling. Entry 
variables will be aaded to iodd_static so each of the common 
ariver subroutines (e.g., ioda_l i sten__ and inputs cmd_) can 
have standard calls to perform driver specific functions. 

New driver modules may need new data from io_daemon_parms. 
Therefore, to avoid modifying several programs and data 
structures for each new driver, the method of specifying the 
major ana minor aevice attributes in the io_aaemon_parms file 
needs to be generalized. Only those attributes which are 
needed during the common initialization of all drivers will 
have keyworas in the pans tile. Those attributes which may 
be more aynamic, on a per driver module basis, will be 
described by a quoted string after the new keyword "args". 
This allows the aaoition of new driver control moaules to be 
completely parameter i zed. . .no recompi I at ion should be 
necessary. 

The format of the user request aata structure which is stored 
in the message segment must also become more general. This 
will allow aevice options ana driver options to be tailored to 
each driver module rather than changing one include file and 
recompiling all modules which use it (currently there are nine 
(9) external procedures which reference dpr in t_msg. inc I .p I 1 ) • 
We will establish a standard header structure which will 
define that part of the request data which must be known by 
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the coordinator as well as all drivers. The "pr int_punch" 
variable will be changed to indicate the driver module which 
is expected to perform the request. Only the driver module 
and the command setting the value need to agree on the value 
(but it must be unique among driver modules). Each driver 
module will check to ensure that the request is meant for that 
particular driver. Then the remainder of the request data can 
be interpreted on a per driver module basis. The coorainator 
does not care how long the request is? it only needs the 
time f pathname t delete switch and version of the request 
heaaer. 



IV. Summary 

These proposed changes provide the structure needed to 
completely generalize the driver software. A new type of 
device driver can be added by writing a driver mooule which 
meets the conventions and knows how to control the device. 
Then the io__daemon_parms file can be edited by an 
aaministrat or to include the new device, device class and 
other attributes. 

The operator interface will not change for the new driver 
except for new driver specific commands. Each driver can make 
use of the same overseer* which will handle all initial 
ari ver-coord inat or protocol. Some of the driver subroutines 
can be directly used by the new driver module without changes? 
others can be easily tailored to meet new requirements. 

These changes imply that almost every module of the current 
driver process will be either rewritten, restructured or 
removed. Driver modules for controlling the printer* punch 
and mohawk devices will have to be written. At installation 
time, all driver modules and io_daemon_parms will have to be 
replacea since they will now be incompatible with older 
versi ons • 
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APPENDIX I 

10 DAEMON PA RMS KEYWORD LIST - ORDERED BY OCCURENCE 



/* PL/I style comments may appear anywhere in the parms file */ 

There are two keywords which specify global values for the 10 
coordinator ana must appear at the beginning of the parms file* 



Time : 



Defines the time in minutes that each 
completed request will be saved to allow for 
restarting. Normally* a delete option will 
not be completed until after this time has 
el aosed. 



Max_queues* 



Defines the maximum number of message segment 
queues to be created or read for each queue 
group defined. 



The next group of keywords are used to define the devices which 
driver processes may use. The device data is used oy the 10 
coordinator to build the "device_tab I e". All device definitions 
must appear ahead of the aevice class definitions. 



Devi ce I 



Defines the name of 
(required - 32 char max) 



ma | or 



device 



dr i ver_modul e: 



Defines the pathname or search name of the 
program which runs the device 

(required - 168 char max) 



ar gs 2 



Defines an arbitrary character string for the 
driver module to decode which describes the 
major device. (optional - 128 char max) 



chan ne I : 



dev_dia I _id« 



Defines the I0M channel of the device for 
direct attachment by the process. This must 
be specified if the dev_dial__id keyword is 
omitted and must be omitted if the 
dev_dial_.id is specified. (8 char max) 

Defines the dial_id to be used if the device 
is to be dialed to the process over a tty 
channel. Immediate attachment to a hard 
wired tty channel will be specified in the 
dial table if desired by the site. This 
keyword may not oe specified if the channel 
keyword is used. (8 char max) 
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ct I _dia I id* Defines the dial id to be used for the 

control terminal to be Dialed to the process. 
Optional - if omitted* no control terminal is 
required for the driver, 

(optional - 8 char max) 

ctl_device: Defines the device name expected for the 

attachment of the control terminal. Example* 
ctll for the message coordinator, netl03 for 
the arpa net* ttyikZ for the 0N355. This 
keyword is primarily included for the message 
coordinator since there will be no check to 
ensure that this is the actual channel 
assigned. (optional - 8 char max) 

minor_devices Defines the name of a minor device associated 

with the last named major device. If omitted* 
the minor device name is taken to be the same 
as that of the major device, 

(optional - 32 char max) 

argsi After the minor device keyword* args defines 

another arbitrary character string used by 
the driver module to describe the minor 
device. There may be one args keyword per 
minor device. If omitted for any minor 
device* a null character string is assumed, 
(optional - 128 char max) 

default _c I as st Defines the default device class to be used 

for this minor device. If omitted* the 
operator must specify the device class during 
initialization. (optional - 32 char max) 

like* This keyword is used to reduce the amount of 

text in the parms fife when there are several 
major devices with similar attributes. All 
missing attributes in the specification of 
the major device* including minor device 
names* are taken from the major device name 
which is the value of the keyword, 
(optional - 32 char max) tNote* the major 
device named must have been previously 
specified if the file.] 



The following keywords define the device classes used by the 10 

coordinator and drivers. The device class definitions must 

follow the definitions of the devices to help simplify the 
parsing of the parms file. 
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Dev i ce_c I ass i 
dev i ce s 



dri ver_user ios 



acco un t i ngt 



queu e_group i 



min_access__c lass 



max_access_classt 



Oefines the 
(required - 



name of 
32 char 



a dynamic 
max ) 



device class. 



Oefines a minor device which may process 
requests of the last named Device_c I ass • One 
or more instances of this keyword must be 
associatea with a device class* The value is 
of the form major. minor to distinguish 
between minor devices of the same name in 
different major devices* If only one 
component is specified as the value, then 
major.major is assumed, 

(required - 65 char max) 

Defines the only process group id which may 
be used to handle requests in this device 
class. If omitted. IO.SysDaemon is assumed. 
A personid of * is allowed, but the projectid 
must be specified. (optional - 32 char max) 

Defines the pathname of the accounting 
procedure to be used for the driver. If 
omitted, or if the value of "system" is 
specified, the standard system accounting 
procedure will be used. The accounting 
procedure specified must be found during 
process initialization, or the driver will 
abort. (optional - 168 char max) 

Oefines the message segment queues to be used 
for requests in this device class. If 
omitted, the queue group will be taken to be 
the same as the device class. Examples 
printer means use the pr inter_IM.ras queues, 
(optional - 32 char max) 

Oefines the lowest access class request which 
a driver of this device class may process 
from the specified queue group. If omitted, 
the system_low access class will be assumed. 
The string must be acceptable to the 
conver t_authorizat ion__ subroutine, 
(op t iona I ) 

Oefines the highest access class request 
which a driver of this device class may 
process from the specified queue group. The 
access authorization of the driver must be 
equal or greater than this value. The 
max_access_c I ass must be equal or greater 
than the min_access_c I ass according to the 
rules of the access isolation mechanism. If 
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omitted, the value of min_access_c 1 ass is 
assumed. The string must be acceptable to 
the convert_author izat ion_ subroutine* 
(optional ) 

<r»in_banner 8 Oetines the lowest access class to be used in 

marking the output generated by a driver 
process* If omittea. the value of 
mi n_access_c I ass is assumed. The string must 
be acceptable to the convert__author izat ion_ 
subroutine. {optional) 

End: This keyword has no value associated with it. 

It only serves to define the end of the parms 
file, (required) 
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